當工程師只會寫 Code：為什麼你的決策總是出錯？

一個觀察出來的經驗

幾年前，一位前輩同事在專案中堅持使用微服務架構 (Microservices)。
他的理由很充分：「這是業界最佳實踐」、「Netflix 和 Amazon 都這樣做」、「可擴展性 (Scalability) 更好」。

當時的我經驗不夠，聽一聽認為很棒，就跟他一起執行了。

團隊只有五個人，後來每次 Debug 都要跨三個服務追蹤，部署流程複雜到讓人崩潰，開發速度慢得像烏龜。
半年後我們默默地把它改回單體架構 (Monolithic)，開發體驗跟專案才漸入佳境。

當時我們很困惑：明明做了大量技術調研，為什麼還會做出這麼糟糕的決策？
直到讀了查理·蒙格 (Charlie Munger) 的《窮查理的普通常識：巴菲特50年智慧合夥人查理．蒙格的人生哲學》，才發現問題出在哪裡——我們只用了一個思維模型在思考，而忽略了其他所有維度。

工程師的思維盲區：單一視角的危險

工程師最擅長的，是用技術的角度解決問題。

我們熟悉演算法的時間複雜度、資料結構的優劣、設計模式的應用。
但現實世界的問題，從來不是單純的技術問題。

當我堅持用微服務時，我的思考模型是：

• ✅ 技術視角：微服務更現代、更符合潮流。
• ❌ 規模視角：完全沒考慮團隊規模與複雜度的匹配。
• ❌ 成本視角：沒評估維護成本和學習曲線。
• ❌ 人性視角：沒想過團隊成員是否有能力駕馭。

我用一把錘子 (Hammer) 看世界，於是所有問題都變成了釘子 (Nail)。這就是蒙格說的「鐵錘人傾向 (Man with a Hammer Syndrome)」。

查理·蒙格的智慧：多元思維模型 (Mental Models)

查理·蒙格是華倫·巴菲特 (Warren Buffett) 的黃金搭檔，波克夏·海瑟威 (Berkshire Hathaway) 的副董事長。

但比起他在投資上的成就，更讓我敬佩的是他對「思考本身」的深度鑽研。
他在書中提出一個核心觀念：

"你必須擁有多個思維模型，並且這些模型必須來自不同學科。"

他把思考比喻成工具箱 (Toolbox)。
一個只有錘子的工具箱，永遠無法處理複雜的問題。你需要有板手、螺絲起子、鉗子、水平儀⋯⋯每個工具都有它適用的場景。

而這些「工具」，就是來自不同學科的思維模型：

• 經濟學：機會成本 (Opportunity Cost)、邊際效益 (Marginal Utility)
• 心理學：認知偏誤 (Cognitive Bias)、激勵機制 (Incentive)
• 物理學：臨界質量 (Critical Mass)、槓桿原理 (Leverage)
• 生物學：適者生存 (Survival of the Fittest)、生態位 (Niche)
• 數學：複利效應 (Compound Effect)、機率思維 (Probabilistic Thinking)

蒙格強調，這些模型不是孤立的知識點，而是要交織成一張「思維格柵 (Latticework of Mental Models)」，讓你從多個維度去審視同一個問題。

我從書中學到的三個關鍵思考工具

讀完這本書後，我開始刻意練習蒙格的思維方式。
以下是對我影響最深的三個模型：

1. 逆向思考 (Inversion)：先想怎麼搞砸它

蒙格有句名言：

"告訴我我會死在哪裡，這樣我就永遠不會去那個地方。"

與其問「怎樣做才能成功？」，不如先問「怎樣做會失敗？」然後避開所有導致失敗的路徑。

這個思維模型徹底改變了我做架構設計的方式。

過去的我：設計一個系統時，先想「我要加哪些功能、用哪些技術」。

現在的我：先列出所有可能讓系統崩潰的原因：

• 單點故障 (Single Point of Failure)
• 資料庫連線池 (Connection Pool) 耗盡
• 記憶體洩漏 (Memory Leak)
• 沒有備份機制 (Backup)
• API 沒有限流 (Rate Limiting)

然後一一消除這些風險。
這種「防禦性設計」讓我的系統穩定性提升了好幾個層次。

2. 激勵機制 (Incentive)：人會做對自己有利的事

蒙格說：

"永遠不要低估激勵的力量。"

這個模型讓我重新理解了團隊協作中的許多問題。

曾經我很困擾：為什麼 Code Review 總是流於形式？為什麼大家寫文件都不認真？

後來我發現，問題不在「人懶惰」，而是「沒有正確的激勵機制」。

如果寫文件不會被看見、不會被感謝、不會影響績效，那誰會認真寫？
如果 Code Review 只是「走流程」，沒有真正的討論和學習，那誰會投入心力？

於是我開始調整機制：

• 文件撰寫者：每週分享會上表揚最佳文件，並記錄到績效中。
• Code Review：把「提出有價值的建議」也列入評估標準。

當激勵對齊 (Alignment of Incentives) 之後，團隊的行為模式就自然改變了。

3. 複利效應 (Compound Effect)：微小改進的巨大力量

這個模型來自數學，但蒙格把它應用到人生的各個層面。

每天進步 1%，一年後你會成長 37 倍；每天退步 1%，一年後你會衰退到只剩 3%。

公式是：1.01^365 = 37.78 vs 0.99^365 = 0.03

這個觀念讓我開始重視「微小但持續的改進」。

我不再追求一次性的大躍進，而是專注於建立每天都能執行的小習慣：

• 每天讀 10 頁技術文件
• 每週重構一小段程式碼
• 每月分享一次學習心得

這些看似微不足道的行動，累積一年後，我驚訝地發現自己的成長遠超預期。

如何建立你的「思維工具箱」？

讀完《窮查理的普通常識》後，我開始為自己建立一套「多元思維模型」的實踐流程：

Step 1：收集模型 - 從不同學科中學習

我開始有意識地閱讀不同領域的書籍：

• 心理學：《快思慢想》、《影響力》
• 經濟學：《經濟學原理》、《魔鬼經濟學》
• 生物學：《自私的基因》
• 歷史學：《人類大歷史》

每讀完一本書，我會在筆記中記錄 2-3 個核心思維模型，並用自己的話重新詮釋。

Step 2：練習應用 - 在真實場景中使用

每當遇到需要做決策的場景，我會刻意問自己：

1. 從技術角度看，最優解是什麼？（工程思維）
2. 從成本角度看，哪個方案投資報酬率最高？（經濟思維）
3. 從人性角度看，團隊成員會如何反應？（心理思維）
4. 從風險角度看，最壞的情況是什麼？（逆向思維）

透過多角度的審視，我的決策品質明顯提升。

Step 3：建立檢查清單 (Checklist)

蒙格強調，人的記憶力和意志力都不可靠，所以要用系統來避免犯錯。

我為自己建立了一份「架構設計檢查清單」：

## 架構設計檢查清單

### 技術維度
- [ ] 是否符合現有技術棧？
- [ ] 是否有成熟的解決方案？
- [ ] 可擴展性如何？

### 成本維度
- [ ] 開發成本是多少？
- [ ] 維護成本是多少？
- [ ] 學習曲線如何？

### 人性維度
- [ ] 團隊是否有能力駕馭？
- [ ] 是否會影響士氣？
- [ ] 激勵機制是否到位？

### 風險維度
- [ ] 最壞的情況是什麼？
- [ ] 有哪些單點故障？
- [ ] 是否有退路？如何快速回滾 (Rollback)？

每次做重大決策前，我都會過一遍這份清單。
這個簡單的動作，幫我避免了無數次的錯誤。

超越「只會寫 Code」的工程師

查理·蒙格在書中說：

"如果你只是記得一些孤立的事實，試圖把它們硬湊起來，那你無法真正理解任何東西。"

這句話深深撼動了我。

我們花了那麼多時間學習框架、語言、工具，但真正拉開工程師層次的，往往不是技術本身，而是你如何思考問題、如何做出決策、如何避免認知盲區。

《窮查理的普通常識》教會我的，不只是幾個思維模型，而是一種對「思考本身」的敬畏與追求。

一起建立屬於我們自己的「思維工具箱」吧。
當你擁有多元的視角，你會發現，世界比你想像的更立體、更有趣，而你的決策，也會變得更明智。

#窮查理的普通常識 #多元思維模型 #逆向思考 #吳桑泥的升級書單 #工程師思維 #決策能力